fix(serializers): refuse AutoSerializer datetimes that read back as another value (LAB-12972) - #723

Description

AutoSerializer now refuses at write two datetime values that would read back as another value:

• A pandas Timestamp with non-zero nanoseconds raises TypeError, bare or inside any container. Its ISO text kept all nine digits, but datetime.fromisoformat keeps six, so a lone value came back truncated, Timestamps 1 ns apart in a set collapsed into one element with no error, and nine of them, or two frozensets of them, failed every read under the set bound from #721. pd.NaT is a datetime but not a Timestamp, so it is never refused.
• A set or frozenset holding an aware datetime whose UTC offset depends on fold, a wall time its zone repeats or skips, at either fold, raises TypeError, whether the datetime is an element or sits at any depth inside one of the set's tuples. PEP 495 makes such a datetime unequal to every datetime in another zone, but it is stored with its offset and without fold, so it reads back as a fixed-offset datetime that can equal another element. With d the first 01:30 of New York's repeated hour, {d, d.astimezone(UTC)} wrote two elements and read back one; at fold=1, {frozenset({d1}), frozenset({utc})} failed every read. Naive and fixed-offset (UTC included) datetimes are never refused. Outside a set the same datetime writes the same bytes as before.

No stored format changes. Every value that is not refused writes byte-identical payloads, and tests pin the bytes for a zero-nanosecond Timestamp, a plain datetime, and a fold=1 datetime bare, in a list and as a dict value. Keeping nanoseconds or fold would need a new stored field on the __datetime__ marker the protocol shares, so it is out of this change.

The refusal message says what to do: ts.floor("us") or ts.value for a Timestamp, dt.astimezone(timezone.utc) for a fold-dependent datetime.

Docs

• docs/serializers/auto.md: the "What It Preserves" row says datetime round-trips to the microsecond, and a new paragraph states the Timestamp behaviour (exact to the microsecond, sub-microsecond refused at write, pd.NaT written but unreadable). The "Set Size Bound" residual paragraph now says the writer refuses these sets, and names them only as entries an earlier version wrote.
• docs/error-codes.md: "Serialization unsupported type" lists the two new TypeErrors; the set-bound paragraph of "Deserialization failed" names these sets as written by an earlier version.

Cost

The fold check walks a set's elements and its tuples a level at a time in C passes; only datetimes outside a fixed-offset zone reach Python, which calls utcoffset() at both folds. It is skipped for a set of only str and bytes. Measured on serialize() of one set, guard on against guard off: 1,024 UTC datetimes +5%, 1,024 America/New_York datetimes +31% (about 0.4 ms), 1,024 nested 3-tuples +14%, 100k strings no change. Reads are unchanged.

Testing

• tests/unit/test_auto_serializer_new_types.py: the old test that asserted the 8-Timestamp collapse and the read-side refusal now asserts TypeError at write for the set of 8, the set of 9 and the frozenset pair. A new TestAutoSerializerDatetimeRoundTrip pins the nanosecond refusal in each container, pd.NaT, the byte-identical payloads, eight fold-dependent set shapes (fold=1 and fold=0 in a repeated hour, both folds in a skipped hour, bare, in tuples and in frozensets), and that naive, fixed-offset and unambiguous zoned datetimes still round-trip.
• Against the base commit, the 10 new refusal tests fail and the 4 byte-identity and non-refusal tests pass.
• pytest tests --ignore=tests/fuzzing -m "not slow" -n auto: 8624 passed, 109 skipped. ruff check, ruff format --check and basedpyright pass.

Closes LAB-12972